%****************************************************************************%
%* DIET User's Manual installing chapter file                               *%
%*                                                                          *%
%*  Author(s):                                                              *%
%*    - Eddy CARON (Eddy.Caron@ens-lyon.fr)                                 *%
%*    - Pushpinder Kaur Chouhan (Pushpinder.Kaur.Chouhan@ens-lyon.fr)       *%
%*    - Philippe COMBES (Philippe.Combes@ens-lyon.fr)                       *%
%*                                                                          *%
%* $LICENSE$                                                                *%
%****************************************************************************%
%* $Id: install.tex,v 1.42 2008/07/17 09:58:54 bdepardo Exp $
%* $Log: install.tex,v $
%* Revision 1.42  2008/07/17 09:58:54  bdepardo
%* Added a line on the static compilation on Mac systems
%*
%* Revision 1.41  2008/07/15 23:11:45  ecaron
%* Typo
%*
%* Revision 1.40  2008/07/14 09:33:37  vpichon
%*
%* documentation section move UserManual => ProgrammersGuide
%*
%* Revision 1.39  2008/07/09 15:26:20  dloureir
%* Removing the fixme concerning the batch option
%*
%* Revision 1.38  2008/07/09 15:18:08  dloureir
%* So the good answer for DIET_USE_BATCH or DIET_USE_ALT_BATCH is DIET_USE_ALT_BATCH.
%*
%* Revision 1.37  2008/07/09 14:52:31  dloureir
%* Adding a fixme concerning DIET_USE_BATCH and DIET_USE_ALT_BATCH options. Because both options exist in different files of DIET and when compiling DIET with DIET_USE_BATCH and Appleseed it does not work...
%*
%* Revision 1.36  2008/07/07 14:05:52  vpichon
%*
%* ajout partie compilation de la doc.
%*
%* Revision 1.35  2008/04/08 09:41:40  bdepardo
%* linebreaks to prevent overfull hbox
%*
%* Revision 1.34  2008/04/07 23:55:37  ecaron
%* Fix overfull box
%*
%* Revision 1.33  2008/03/28 13:18:14  rbolze
%* add support for XL compiler (IBM) and intel compiler
%*
%* Revision 1.32  2007/09/06 13:51:37  dloureir
%* Addition of the Linux AIX support and correction of some faults.
%*
%* Revision 1.31  2006/12/05 13:25:20  eboix
%*  FIX: Chapter 2 of User's manual typos and errors removed (many thanks to
%*       Abdelkader for reading and suggesting fixes).  --- Injay2461
%*
%* Revision 1.30  2006/11/15 14:58:16  eboix
%*    First autotools free version. --- Injay2461
%*
%* Revision 1.29  2006/11/15 13:55:16  eboix
%*   Separation from cmake and autotools.  --- Injay2461
%*
%****************************************************************************%

\chapter{DIET installation}
\label{ch:installing}

%====[ Dependencies ]==========================================================
\section{Dependencies}
\label{sec:dependencies}

\subsection{General remarks on DIET platform dependencies}

DIET is itself written in C/C++ and for limited parts in java. DIET is
based on CORBA and thus depends on the chosen CORBA implementation.
Additionally, some of DIET extensions make a strong use of libraries
themselves written in C/C++ and java.
Thus, we could expect DIET to be effective on any platform offering
decent version of such compilers.

DIET undergoes daily regression tests
(see \url{http://graal.ens-lyon.fr/DietDashboard})
on various hardwares, a couple of Un*x based operating systems (under
different distributions), MacOSX and AIX, and mainly with GCC.
But, thanks to users reports (punctual deployments and special tests
conduced before every release), DIET is known to be effective on a
range of platforms.

Nevertheless, if you encounter installation difficulties don't hesitate
to post on DIET's users mailing list: \verb+diet-usr@listes.ens-lyon.fr+
(for the archives refer to \url{http://graal.ens-lyon.fr/DIET/mail-lists.html}).
If you find a bug in DIET, please don't hesitate to submit a bug report on
\url{http://graal.ens-lyon.fr/bugzilla}. If you have multiple bugs
to report, please make multiple submissions, rather than submitting
multiple bugs in a single report.

\subsection{Hardware dependencies}
DIET is fully tested on Linux/i386 and Linux/i686 platforms.
DIET is known to be effective on Linux/Sparc, Linux/i64, Linux/amd64,
Linux/Alpha, Linux/PowerPC, AIX/PowerPC and MacOS/PowerPC platforms.
At some point in DIET history, DIET used to be tested on the Solaris/Sparc
platform...

\subsection{Supported compilers}
DIET is supported on GCC with versions ranging from 3.2.X to 4.1.x.
Note that due to omniORB 4 (see \ref{sec:software_dependencies}) requirements
towards thread-safe management of exception handling, compiling DIET with
\verb+gcc+ requires at least \verb+gcc-2.96+.
DIET is also supported on XL complier(IBM) and Intel compiler.

\subsection{Operating system dependencies}
DIET is fully tested on Linux [with varying distributions like Debian,
Red Hat Enterprise Linux (REL-ES-3), Fedora Core (5)], on AIX (5.3) and on MacOSX
(Darwin 8).

\subsection{Software dependencies}
\label{sec:software_dependencies}

As explained in Section~\ref{sec:CORBA}, CORBA is used for all
communications inside the platform.
The implementations of CORBA currently supported in DIET is
\textbf{omniORB 4} which itself depends on \textbf{Python}.

\noindent 
\textbf{NB:} We have noticed that some problems occur with
\textbf{Python 2.3}: the C++ code generated by idl could not be compiled.
It has been patched in DIET, but some warnings may still appear.

\textbf{omniORB 4} itself also depends on \textbf{OpenSSL} in case
you wish to secure your DIET platform.
If you want to deploy a secure DIET platform, SSL support is not yet
implemented  in DIET, but an easy way to do so is to deploy DIET over
a VPN.

In order to deploy CORBA services with omniORB, a configuration file
and a log directory are required: see Section \ref{sec:CORBA_services}
for a complete description of the services.  Their paths can be given
to omniORB either at runtime (through the well-known environment
variables \texttt{\$OMNIORB\_CONFIG} and 
\texttt{\$OMNINAMES\_LOGDIR}), and/or at omniORB compile time (with 
the \linebreak\texttt{--with-omniORB-config} and \texttt{--with-omniNames-logdir} options.)
Some examples provided in the DIET sources depend on the BLAS
and \scalapack\ libraries. However the compilation of those BLAS and
\scalapack\ dependent examples are optional.

%====[ Compilation ]===========================================================
\section{Compiling the platform}
\label{sec:compil_platform}

DIET compilation process moved away from the traditional \verb+autotools+
way of things to a tool named \verb+cmake+ (mainly to benefit from
\verb+cmake+'s built-in regression tests mechanism).

Before compiling DIET itself, first install the above mentioned
(cf Section~\ref{sec:software_dependencies}) dependencies.
Then untar the DIET archive and change current directory to its root directory.

%==================
\subsection{Obtaining and installing cmake per se}
DIET requires using \verb+cmake+ at least version \verb+2.4.3+.
For many popular distributions \verb+cmake+ is incorporated by
default or at least \verb+apt-get+ (or whatever your distro package installer
might be) is \verb+cmake+ aware.
Still, in case you need to install an up-to-date version \verb+cmake+'s
official site distributes many binary versions (alas packaged as tarballs)
which are made available at 
\url{http://www.cmake.org/HTML/Download.html}.
Optionally, you can download the sources and recompile them: this simple
process (\verb+./bootstrap; make; make install+) is described at
\url{http://www.cmake.org/HTML/Install.html}.

%==================
\subsection{Configuring DIET's compilation: cmake quick introduction}
If you are already experienced with \verb+cmake+ then using it to compile
DIET should provide no surprise. 
DIET respects \verb+cmake+'s best practices e.g.~by clearly separating the
source tree from the binary tree (or compile tree), by exposing the main
configuration optional flag variables prefixed with \verb+DIET_+ (and by
hiding away the technical variables) and by not postponing configuration
difficulties (in particular the handling of external dependencies like
libraries) to compile stage.

\verb+Cmake+ classically provides two ways for setting configuration
parameters in order to generate the makefiles in the form of two
commands \verb+ccmake+ and \verb+cmake+ (the first one has an extra "c"
character):
\begin{description}
\item{\verb+ccmake [options] <path-to-source>+}\\
  in order to specify the parameters interactively through a GUI interface
\item{\verb+cmake [options] <path-to-source> [-D<var>:<type>=<value>]+}\\
  in order to define the parameters with the \verb+-D+ flag directly
  from the command line.
\end{description}
In the above syntax description of both commands, {\verb+<path-to-source>+}
specifies a path to the top level of the source tree (i.e. the directory
where the top level CMakeLists.txt file is to be encountered). Also
the current working directory will be used as the root of the build tree for
the project (out of source building is generally encouraged especially
when working on a CVS tree).

\noindent
Here is a short list of \verb+cmake+ internal parameters that are worth
mentioning:
\begin{itemize}
\item
  \verb+CMAKE_BUILD_TYPE+ controls the type of build mode among which 
  \verb+Debug+ will produce binaries and libraries with the debugging
   information
\item
   \verb+CMAKE_VERBOSE_MAKEFILE+ is a Boolean parameter which when set to
   ON will generate makefiles without the .SILENT directive. This is
   useful for watching the invoked commands and their arguments in case
   things go wrong.
\item
   \verb+CMAKE_C[XX]_FLAGS*+ is a family of parameters used for
   the setting and the customization of various C/C++ compiler options.
\item
   \verb+CMAKE_INSTALL_PREFIX+ variable defines the location
   of the install directory (defaulted to \verb+/usr/local+ on un*x).
   This is cmake's portable equivalent of the autotools configure's
   \texttt{--prefix=} option.
\end{itemize}
%
Eventually, here is a short list of \verb+ccmake+ interface tips:
\begin{itemize}
\item
  when lost, look at the bottom lines of the interface which always
  summarizes \verb+ccmake+'s most pertinent options (corresponding
  keyboard shortcuts) depending on your current context
\item
  hitting the "h" key will direct you \verb+ccmake+ embedded tutorial
  and a list of keyboard shortcuts (as mentioned in the bottom
  lines, hit "e" to exit)
\item
  up/down navigation among parameter items can be achieved with the
  up/down arrows
\item
  when on a parameter item, the line in inverted colors (close above the
  bottom of the screen) contains a short description of the selected
  parameter as well as the set of possible/recommended values
\item
  toggling of boolean parameters is made with enter
\item
  press \verb+enter+ to edit path variables
\item
  when editing a \verb+PATH+ typed parameter the \verb+TAB+ keyboard
  shortcut provides an emacs-like (or bash-like) automatic path completion.
\item
  toggling of advanced mode (press "t") reveals hidden parameters
\end{itemize}
 
%==================
\subsection{A ccmake walk-through for the impatients}

Assume that \verb+CVS_DIET_HOME+ represents a path to the top level
directory of DIET sources.
This DIET sources directories tree can be obtained by DIET users by
expanding the DIET current source level distribution tarball.
But for the DIET developers this directories tree simply corresponds to
the directory GRAAL/devel/diet/diet of a cvs checkout of the DIET sources
hierarchy.
Additionally, assume we created a build tree directory and \verb+cd+
to it (in the example below we chose \verb+CVS_DIET_HOME/Bin+ as
build tree, but feel free to follow your conventions):
\begin{itemize}
\item
  \verb+cd CVS_DIET_HOME/Bin+
\item
  \verb+ccmake ..+ to enter the GUI
  \begin{itemize}
  \item press \verb+c+ (equivalent of bootstrap.sh of the autotools)
  \item toggle the desired options e.g. \verb+DIET_BUILD_EXAMPLES+ or
     \verb+DIET_USE_JXTA+. 
  \item specify the \verb+CMAKE_INSTALL_PREFIX+ parameter (if you wish
     to install in a directory different from \verb+/usr/local+)
  \item press \verb+c+ again, for checking required dependencies
  \item check all the parameters preceded with the * (star) character
     whose value was automatically retrieved by \verb+cmake+.
  \item provide the required information i.e. fill in the proper values
     for all parameters whose value is terminated by NOT-FOUND
  \item iterate the above process of parameter checking, toggle/specification
     and configuration until all configuration information is satisfied
  \item press \verb+g+ to generate the makefile
  \item press \verb+q+ to exit ccmake
  \end{itemize}
\item
  \verb+make+ in order to classically launch the compilation process
\item
  \verb+make install+ when installation is required
\end{itemize}

%==================
\subsection{DIET's main configuration flags}

Here are the main configuration flags:
\begin{itemize}
\item
  \verb+OMNIORB4_DIR+ is the path to the omniORB4 installation directory
  (only relevant when omniORB4 was not installed in /usr/local).\\
  Example: \verb+cmake .. -DOMNIORB4_DIR:PATH=$HOME/local/omniORB-4.0.7+

\item
  \verb+DIET_BUILD_EXAMPLES+ activates the compilation of a set of
  general client/server examples. Note that some specific examples
  (e.g. \verb+DIET_BUILD_BLAS_EXAMPLES+) require some additional flag
  to be activated too.

\item
  \verb+DIET_BUILD_LIBRARIES+ which is enabled by default, activates the
  compilation of the DIET libraries.
  Disabling this option is only useful if you wish to restrict the
  compilation to the construction of the documentation.
\end{itemize}

%==================
\subsection{DIET's extensions configuration flags}

DIET has many extensions (some of them are still) experimental. These
extensions most often rely on external packages that need to be pre-installed.
One should notice that some of those extensions offer concurrent
functionalities.
This explains the usage of configuration flags in order to obtain
the compilation of the desired extensions.

\begin{itemize}
\item
  \verb+DIET_USE_ALT_BATCH+ enables the transparent submission to batch servers. See Chapter~\ref{chapter:parallelSubmission} for more details.

\item
  \verb+DIET_BUILD_BLAS_EXAMPLES+ option activates the compilation of
  the BLAS based DIET examples, as a sub-module of examples.
  The BLAS~\footnote{\url{http://www.netlib.org/blas/}} (Basic Linear
  Algebra Subprograms) are high quality ``building block'' routines for
  performing basic vector and matrix operations.
  Level 1 BLAS do vector-vector operations, Level 2 BLAS do matrix-vector
  operations, and Level 3 BLAS do matrix-matrix operations.
  Because the BLAS are efficient, portable, and widely available,
  they're commonly used in the development of high quality linear algebra
  software.
  DIET uses BLAS to build demonstration examples of client/server.
  Note that the option \verb+DIET_BUILD_BLAS_EXAMPLES+ can only be
  effective when \verb+DIET_BUILD_EXAMPLES+ is enabled.
  \verb+DIET_BUILD_BLAS_EXAMPLES+ is disabled by default.

\item
  \verb+DIET_USE_CORI+ CoRI, which stands for COllector of Resource
  Information, provides a framework for probing hardware and performance
  information about the SeD.
  CoRI also yields a very basic set of probing resources which are
  heavily dependent on the system calls available for the considered platform.
  When this option is activated (disabled by default), the user can either
  define new collectors or use existing collectors (like FAST, see the
  \verb+DIET_USE_FAST+ option) through CoRI's interface.
  CoRI thus provides a possible tactical approach for tuning the performance
  of your favorite plug-in scheduler.
  Chapter~\ref{chapter:performance} describes in more details CoRI and its
  possible usage within DIET.

\item
  \verb+DIET_USE_FAST+ activates DIET support of FAST (refer to
  \url{http://www.loria.fr/~quinson/fast.html} a grid aware dynamic
  forecasting library.
  Although the detection of FAST should be correctly handled by cmake
  (since detection is based on the FAST provided \verb+fast-config+ utility)
  the installation of FAST can be a lengthy process (and, depending on your
  platform, potentially quite difficult).
  This is due to the dependency of FAST towards numerous sub-libraries on
  which it relies (GSL, BDB, NWS, LDAP).
  Thus, the activation of this option can only be recommended for advanced
  users...
  As already mentioned, on activation of the \verb+DIET_USE_FAST+ option
  cmake will search among the well known system path for the
  \verb+fast-config+ command and set the \verb+FAST_CONFIG_EXECUTABLE+ 
  with the result. Upon failure, it is up to the user to manually set the
  full path name to this command (e.g. with [c]cmake command line argument \\
  \verb+-DFAST_CONFIG_EXECUTABLE:PATH=$HOME/local/bin/fast-config+.

\item
  \verb+DIET_USE_FD+ for activating Fault Detector.

\item 
  \verb+DIET_USE_JUXMEM+ activates DIET support of JuxMem which allows
  the user to manage persistent data.
  When this option is activated (disabled by default), a SeD can store
  data blocks within JuxMem.
  Chapter~\ref{ch:juxmem} describes in more details JuxMem and its use
  inside DIET.

\item
  \verb+DIET_USE_JXTA+ activates the so called MULTI-Master-Agent
  support.
  This option is which is based on the JXTA layer (refer to
  \url{http://www.jxta.org/}) allows the user to deploy DIET\_JXTA
  architectures.
  Note that this is to be opposed with
  \verb+DIET_WITH_MULTI_MA+ (see \ref{sec:multimainstall} below)
  which offers similar functionalities but based on CORBA.

\item
  \label{sec:multimainstall}
  \verb+DIET_WITH_MULTI_MA+ activates the so called MULTI Master Agent
  support which allows the user to connect several MA for them to
  act as bounded.
  When this option is activated, such a bounded MA is allowed to search
  for a SeD into the MA hierarchies it is connected to.
  Note that MULTI-Master-Agent support is based on the CORBA layer
  which is to be opposed with \verb+DIET_USE_JXTA+ which offers similar
  functionalities but based on JXTA.

\item
  \verb+DIET_USE_WORKFLOW+ enables the support of workflow.

\item
  \verb+DIET_WITH_STATISTICS+ enables the generation of statistics logs
\end{itemize}

%==================
\subsection{DIET's advanced configuration flags}
\noindent

Eventually, some configuration flags control the general result of the
compilation or some developers extensions:
\begin{itemize}
\item
  \verb+BUILD_TESTING+ is a conventional variable (which is not a cmake
  internal variable) which specifies that the regression tests should
  also be compiled.

\item
  \verb+BUILD_SHARED_LIBS+ is a cmake internal variable which specifies
  whether the libraries should be dynamics as opposed to static (on
  Mac system this option is automatically set to \verb!ON!, as
  static compilation of binaries seems to be forbidden on these systems)

\item
  \verb+DIET_USE_DART+ enables DART reporting system (refer to 
  \url{http://public.kitware.com/Dart}) which is used for constructing
  DIET's dashboard (see \url{http://graal.ens-lyon.fr/DietDashboard}).
  Note that setting the \verb+DIET_USE_DART+ will force the option
  \linebreak\verb+BUILD_TESTING+ to be set.

\item
  \verb+Maintainer+ By default cmake offers four different build modes
  that one toggles by positioning \verb+CMAKE_BUILD_TYPE+ built-in
  variable (to \verb+Debug+, \verb+Release+, \verb+RelWithDebInfo+
  and \verb+MinSizeRel+).
  \verb+Maintainer+ is an additional mode which fulfills two basic needs
  of the task of the maintainer of Diet.
  The first preventive task is to provide code free from any compilation
  and link warnings.
  The second corresponds to the snafu stage which is to debug the code.
  For reaching those goals the \verb+Maintainer+ build type sets the
  compilers flags, respectively the linker flags, with all the possible
  warning flags activated, resp. with the additional debug flags.
\end{itemize}

%==================
\subsection{Compiling and installing}

\subsubsection{Summarizing the configuration choices}
Once the configuration is properly made one can check the choices made
by looking the little summary proposed by cmake.
This summary should look like (\verb+[...]+ denotes eluded portions):
{\footnotesize
\begin{verbatim}
~/DIET > ./cmake ..
[...]
 - Install prefix: /home/diet/local/diet
 - OmniORB found: YES
   * OmniORB directory: /home/diet/local/omniORB-4.0.7
   * OmniORB includes: /home/diet/local/omniORB-4.0.7/include
   * OmniORB libraries: /home/diet/local/omniORB-4.0.7/lib/libomniDynamic4.so;
     [...]libomniORB4.so;[...]libomnithread.so;[...]libCOS4.so;[...]
 - General options:
   * Documentation: ON
   * Dynamics Libraries: ON
   * Examples: ON
   * BLAS Examples: ON
 - Options set:
   * Batch: ON
     -- Appleseeds directory: /home/diet/local/appleseeds-2.2.1
     -- Appleseeds includes:  [...]appleseeds-2.2.1/include/appleseeds
     -- Appleseeds library:   [...]appleseeds-2.2.1/lib/libappleseeds.a
   * CORI: ON
   * Dart: ON
   * JXTA: ON
   * JuxMem: ON
[...]
\end{verbatim}
}
A more complete, yet technical, way of making sure is to check the content
of the file named \verb+CMakeCache.txt+ (generated by cmake in the
directory from which cmake was invocated).
When exchanging with the developers list it is a recommendable practice
to join the content of this file which summarizes your options and also
the automatic package/library detections made by cmake.

\subsubsection{Compiling stage}
You are now done with the configuration stage (equivalent of both the
\verb+bootstrap.sh+ and \verb+./configure+ stage of the \verb+autotools+).
You are now back to your platform level development tools i.e.~\verb+make+
when working on Unices.
Hence you can now proceed with the compiling process by launching \verb+make+.

\subsubsection{Testing}
If you configured DIET with the \verb+BUILD_TESTING+ you can easily run
the regression tests by invoking the \verb+make test+.
This is equivalent to invoking \verb+ctest+ command (ctest is part of cmake
package). \verb+ctest --help+ provides a summary of the advanced options
of \verb+ctest+ among which we recommend the \verb+--verbose+ option.

\subsubsection{Installation stage}
After compiling (linking, and testing) you can optionally proceed with
the installation stage with the \verb+make install+ command.

%==============================================================================
\section{Diet client/server examples}
\label{section:diet-examples}

A set of various examples of DIET server/client are provided within
the DIET archive:
\begin{itemize}
\item{\texttt{file\_transfer}}: the server computes the sizes of two
  input files and returns them. A third output parameter may be
  returned; the server decides randomly whether to send back the
  first file. This is to show how to manage a variable number of
  arguments: the profile declares all arguments that may be filled,
  even if they might not be all filled at each request/computation.

\item{\texttt{dmat\_manips}}: the server offers matrix manipulation
  routines: transposition (\texttt{T}), product (\texttt{MatPROD}) and
  sum (\texttt{MatSUM}, \texttt{SqMatSUM} for square matrices, and
  \texttt{SqMatSUM\_opt} for square matrices but re-using the memory
  space of the second operand for the result). Any subset of these
  operations can be specified on the command line. The last two of
  them are given for compatibility with a BLAS server as explained below.
  
\item{\texttt{BLAS}}: the server offers the \texttt{dgemm} BLAS
  functionality.  We plan to offer all BLAS (Basic Linear Algebraic
  Subroutines) in the future. Since this function computes
  $C = \alpha AB + \beta C$, it can also compute a matrix-matrix
  product, a sum of square matrices, etc. All these services are
  offered by the BLAS server. Two clients are designed to use these
  services: one (\texttt{dgemm\_client.c}) is designed to use the
  \texttt{dgemm\_} function only, and the other one
  (\texttt{client.c}) to use all BLAS functions (but currently only
  \texttt{dgemm\_}) and sub-services, such as \texttt{MatPROD}.
  
\item{\texttt{\scalapack}}: the server is designed to offer all
  \scalapack\  (parallel version of the LAPACK library) functions but
  only manages the \texttt{pdgemm\_} function so far. The
  \texttt{pdgemm\_} routine is the parallel version of the
  \texttt{dgemm\_} function, so that the server also offers all the
  same sub-services. Two clients are designed to use these services:
  one (\texttt{pdgemm\_client.c}) is designed to use the
  \texttt{pdgemm\_} function only, and the other one
  (\texttt{client.c}) to use all \scalapack\ functions and
  sub-services, such as \texttt{MatPROD}.

\item{\texttt{workflow}}: The programs in this directory are examples that
  demonstrate how to use the workflow feature of diet.
  The files representing the workflows that can be tested are stored in
  xml sub-directory.
  For each workflow, you can find the required services in the corresponding
  xml file (check the path attribute of each node element).
  For the scalar manipulation example, you can use \texttt{scalar\_server}
  that gathers four different elementary services.
\end{itemize}

\subsection{Compiling the examples}
\label{subsection:compiling-examples}

\verb+Cmake+ will set the examples to be compiled when setting the 
\verb+DIET_BUILD_EXAMPLES+ to \verb+ON+ which can be achieved by
toggling the corresponding entry of \verb+ccmake+ GUI's or by adding
\verb+-DDIET_BUILD_EXAMPLES:BOOL=ON+ to the command line
arguments of \verb+[c]cmake+ invocation.
Note that this option is disabled by default.

The compilation of the examples, respectively the installation, is
executed on the above described invocation of \verb+make+, resp. 
\verb+make install+ stages.
The binary of the examples are placed in the 
\texttt{$<$install\_dir$>$/bin/examples} sub-directory of the installation
directory.
Likewise, the samples of configuration files located in
\texttt{src/examples/cfgs} are processed by \texttt{make install} to
create ready-to-use configuration files in \texttt{src/examples/cfgs} and
then copied into \texttt{$<$install\_dir$>$/etc/cfgs}.


